-
Notifications
You must be signed in to change notification settings - Fork 14.1k
Rollup of 5 pull requests #149591
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 5 pull requests #149591
Conversation
This... is a weird test. It has two impls: - `impl<T> From<Foo<T>> for Box<T>` (commented out, more on that later), and - `impl<T> Into<Vec<T>> for Foo<T>` The idea of that test is to show that the first impl doesn't compile, but the second does, thus `TryFrom` should be using `Into` and not `From` (because `Into` is more general, since the `From` impl doesn't compile). However: 1. The types are different -- `Box` vs `Vec`, which is significant b/c `Box` is fundamental 2. The commented out impl actually compiles! (which wasn't detected b/c it's commented out :\ ) Here is a table for compilation of the impls: | | `Vec` | `Box` | |--------|--------------|----------------| | `From` | since 1.41.0 | never | | `Into` | always | not since 1.28 | [godbolt used to test this](https://godbolt.org/z/T38E3jGKa) Order of events: 1. in `1.28` the `incoherent_fundamental_impls` lint becomes deny by default (this is *not* mentioned in the changelog yay) 2. `1.32` changed absolutely nothing, even though this version is credited in the test 3. the test was added (I'm not exactly sure when) (see rust-lang#56796) 4. in `1.41` coherence was relaxed to allow `From`+`Vec` to compile To conclude: since `1.41` this test does nothing (and before that it was written in a way which did not detect this change). It looks to me like today (since `1.41`) we *could* bound `TryFrom` impl with `From` (but now it'd be a useless breaking change of course). Am I missing anything? Is there a useful version of this test that could be written?
We used to allow `T -> !` coercions (yes!! not `! -> T`) in unreachable code. This was later removed during 2018 stabilization attempt, see: - rust-lang#40800 - rust-lang@59688e1 - rust-lang#46325 I've kept `tests/ui/coercion/coerce-to-bang-cast.rs`, as that is a reasonable test for us *not* having `-> !` coercions.
Duplicate of `from_infer_breaking_with_unit_fallback.rs` and `question_mark_from_never.rs`
I don't think they are testing anything anymore
there are only 1 test in that directory, probably created by mistake.
…mingw` `rust-lld` is supposed to live in sysroot, so it doesn't change the behavior of the function, only removes a potential micro-optimization.
…onszelmann Remove an outdated test This... is a weird test. It has two impls: - `impl<T> From<Foo<T>> for Box<T>` (commented out, more on that later), and - `impl<T> Into<Vec<T>> for Foo<T>` The idea of that test is to show that the first impl doesn't compile, but the second does, thus `TryFrom` should be using `Into` and not `From` (because `Into` is more general, since the `From` impl doesn't compile). However: 1. The types are different -- `Box` vs `Vec`, which is significant b/c `Box` is fundamental 2. The commented out impl actually compiles! (which wasn't detected b/c it's commented out :\ ) Here is a table for compilation of the impls: | | `Vec` | `Box` | |--------|--------------|----------------| | `From` | since 1.41.0 | never | | `Into` | always | not since 1.28 | [godbolt used to test this](https://godbolt.org/z/T38E3jGKa) Order of events: 1. in `1.28` the `incoherent_fundamental_impls` lint becomes deny by default (this is *not* mentioned in the changelog yay) 2. `1.32` changed absolutely nothing, even though this version is credited in the test 3. the test was added (I'm not exactly sure when) (see rust-lang#56796) 4. in `1.41` coherence was relaxed to allow `From`+`Vec` to compile To conclude: since `1.41` this test does nothing (and before that it was written in a way which did not detect this change). It looks to me like today (since `1.41`) we *could* bound `TryFrom` impl with `From` (but now it'd be a useless breaking change of course). Am I missing anything? Is there a useful version of this test that could be written?
…=ChrisDenton Fix std::mem::drop rustdoc misleading statement This is a bit misleading, we were discussing this with our Rust team and some people could think that the compiler does some special magic for this specific function and that's not true or well the compiler does something special but for every function. The reality according to my understanding is that this is a normal function that takes ownership of the given value and as with every other function mir building injects Drop Terminators , drop elaboration refines this and then we would insert the corresponding drop glue, then potentially calling Drop::drop. Not sure if it would be best to remove the sentence as this PR does or explaining something along the lines of the previous text.
…, r=lqd Rename supertrait item shadowing lints This follows the lang team decision [here](rust-lang#148605 (comment)) and renames: - `supertrait_item_shadowing_definition` to `shadowing_supertrait_items` - `supertrait_item_shadowing_usage` to `resolving_to_items_shadowing_supertrait_items` The lint levels are left unchanged as allow-by-default until stabilization.
Various never type test improvements I want to make sure that the never type ui tests are actually sensible, and to do so I'm trying to clean them up. This mainly adds comments explaining test purposes and removes outdated stuff. I imagine best reviewed commit-by-commit, I tried to write useful descriptions and group things into small commits. cc `@lcnr` (I removed `fallback`/`nofallback` terminology in b5f82d4)
linker: Remove special case for `rust-lld` in `detect_self_contained_mingw` `rust-lld` is supposed to live inside sysroot, so it doesn't change the behavior of the function, only removes a potential micro-optimization. rust-lang#149178 (comment) r? `@mati865`
|
@bors r+ rollup=never p=5 |
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 568b117627 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 568b117 (parent) -> 83e49b7 (this PR) Test differencesShow 172 test diffsStage 1
Stage 2
Additionally, 106 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 83e49b75e7daf827e4390ae0ccbcb0d0e2c96493 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
|
Finished benchmarking commit (83e49b7): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary -4.7%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 467.615s -> 469.131s (0.32%) |
Successful merges:
rust-lldindetect_self_contained_mingw#149590 (linker: Remove special case forrust-lldindetect_self_contained_mingw)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup